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Abstract - The Midcourse Space Experiment is a BMDO-sponsored scientific satellite set for 
launch within the year. The satellite will collect phenomenology data on missile targets, plumes, 
earth limb backgrounds and deep space backgrounds in the LWIR, visible and ultra-violet spectral 
bands. It will also conduct functional demonstrations for space-based space surveillance. The 
Space-Based Visible sensor, built by Lincoln Laboratory, Massachusetts Institute of Technology, 
is the primary sensor on board the MSX for demonstration of space surveillance. The SBV 
Processing, Operations and Control Center (SPOCC) is the mission planning and commanding 
center for all space surveillance experiments using the SBV and other MSX instruments. The 
guiding principle in the SPOCC Mission Planning System was that all routine functions be 
automated. Manual analyst input should be minimal. Major concepts are: (1) A high level 
language, called SLED, for user interface to the system; (2) A group of independent software 
processes which would generally be run in a pipe- line mode for experiment commanding but can 
be run independently for analyst assessment; (3) An integrated experiment cost computation 
function that permits assessment of the feasibility of the experiment. This paper will report on 
the design, implementation and testing of the Mission Planning System. 

1.0. INTRODUCTION 

The Mid-Course Space Experiment consists of a set of payloads on a satellite being 
designed and built under the sponsorship of Ballistic Missile Defense Organization (formerly, 

Strategic Defense Initiative Organization) of the Department of Defense. The major instruments are 
a set of long-wave infra red sensors being built by Utah State University, a set of sensors 
operating in the visible wavelength and 
ultraviolet wavelengths, being built by Johns 
Hopkins University’s Applied Physics 
Laboratory, and a visible wavelength sensor 
designed and built by Lincoln Laboratory, 

Massachusetts Institute of Technology. The 
satellite bus is being built by JHU/APL who is 
also acting as the integrator for all the payloads 
and associated systems. The MSX satellite, 
shown in Figure 1, is due for launch in late 94 
from the Vandenberg launch complex into a 
near-sun-synchronous orbit. 

1 . 1 . MSX Missions and Operations 

The MSX satellite is being launched to conduct a series of measurements on 
phenomenology of backgrounds, missile targets, plumes and resident space objects (RSOs); and to 
engage in functional demonstrations of detection, acquisition and tracking for ballistic missile 
defense and space-based space (satellite) surveillance missions. 

Eight Principal Investigators are associated with the MSX project. The Pis develop 
experiment plans that are then prioritized by the BMDO’s Mission Planning Team. JHU/APL’s 
Mission Operations Center commands the MSX to carry out the experiments and collect science 
data. The data are returned to the Pis for analysis and for refining the experiments. 
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1.2. SBV Processing, Operations and Control Center (SPOCC) 

The SBV Processing, Operations and Control Center, located at Lincoln Laboratory MIT 
is a component of the J ’ 

APL’s Mission 
Operations Center. In 
this role, SPOCC 
(Ref. 1) generates the 
necessary command- 
ing for the MSX and 
its sensors for all 
space-based space 
surveillance 
experiments defined 
by the PI for 
Surveillance; and 
converts and calibrates 
the returned science 
data before turning 
them over the SPI’s 
Surveillance Data 
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Fig. 2 ; SPOCC Software System Architecture 


Analysis Center. Further, SPOCC maintains the health and status of the Lincoln Laboratory’s SBV 

sensor on board the MSX. The software architecture of SPOCC and its interaction with the MSX 
are shown in Figure 2. 
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SPOCC has four major functions: 

SPOCC provides the facility for translating the Surveillance Pi’s experiments into feasible 
data collection events on the MSX. The Mission Planning System was designed for this 
purpose; 

SPOCC monitors the health and status of the SBV using returned telemetry from the 
spacecraft; J 

SPOCC provides the capability to decommutate and reduce, to engineering units the 
science data collected by the SBV in support of experiments; and 
SPOCC, in association with the SBV brassboard, provides the facilities to alter and test 
software on-board the SBV in response to changing requirements. 

This paper will describe the first part of SPOCC - the Mission Planning System. 

f . „ . f Missi0n Planning System in SPOCC was originally conceived and designed to support 
the detailed commanding of the SBV sensor on the MSX. However, because of changing 
requirements, it has expanded to encompass the commanding of the SPIRIT 3 and UVISI sensors 
also in support of surveillance experiments. This paper will describe the original design* and use 
the other sensors as an example of its (limited) adaptability. 

1.3. SBV Hardware and Software 

A working knowledge of the SBV hardware and software (Ref. 2-4) is essential to 
understand the design choices made in the Mission Planning System. 

The SBV contains of an off-axis imaging telescope with an aperture of 15 cm and a CCD 
camera at the focal plane. The design improves the off-axis light rejection capability of the 
telescope over conventional on-axis designs and thus enables the SBV to point within 100 Km of 
the earth limb without saturation of the focal plane. The camera consists of four CCD arrays each 
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420x420 pixels, laid out along the Z-axis of the spacecraft. The instantaneous field-of-view at each 
local plane is 1.4 deg x 1.4 deg. Distortion due to the off-axis design causes the total instantaneous 
FOV to be ~6.6 deg. x 1.4 deg. 


The SB V carries a redundant pair of Signal Processors whose function is to detect moving 
targets in a stationary background. The Signal Processor (Ref. 3) collects a set of raw camera 
frame data (4-16 frames ) and applies a space-time filtering algorithm on these data If the 
telescope is pointed in an inertially invariant direction, the stars would be stationary and the Signal 
Processor will detect streaks corresponding to any resident space object in the field-of-view of a 
CCD array. If, on the other hand, a RSO is being tracked, its image would appear stationary and 
the stars would generate streaks. Only one focal plane array can be processed at a time. Typically, 
the SP takes a total time of 50 seconds from the initiation of the frame integration on the camera 
focal plane to writing out the results of star and streak detection. The algorithm can be controlled to 
produce a small number of stars for positional reference and a limited number of RSO streaks. A 
data compression of 105 - 106 is achieved by the SP. 

The entire operation of the SB V is internally controlled by an Experiment Controller. Timed 
commands are stored in the EC and sent to the various components. Another major function of the 
EC is to store the results from the Signal Processor in its memory until such time as a downlink 
event can be initiated. 

The SB V has been designed for space-based surveillance of RSOs. The large field-of-view 
enables rapid search. The off-axis design enables low and high altitude RSOs to be detected and 
tracked near the earth limb, near the moon and within 25 deg of the sun without saturation of the 
focal planes. The Signal Processor design optimizes the detection of RSO streaks against a 
stationary background. The data compression, and the collection of positional data on stars and 
streaks, permits positional accuracies of the order of a third of a pixel (4 arcsec) which is adequate 
to support the current requirements of space surveillance. Use of internal memory to store the 
results and downlinking of the data on demand to a ground station enables the SBV to avoid using 
the on-board power-hungry tape recorder for storage of data. Further, as in many low altitude 
experimental satellites, real-time communication is not available and the on-board storage of 
processed results enables the effective use of limited downlink opportunities. & 

X.4. MSX Spacecraft 

A working knowledge of the MSX spacecraft (Ref. 5) and its capabilities and limitations is 
necessary to understand the design of and the design choices made in the SPOCC mission planning 
system. The instruments of concern to the Surveillance PI are the SPIRIT 3 radiometer and the 
UVISI imagers and spectrometers, apart from the SBV. 

The MSX (Figure 1) is a large satellite with all major sensors coaligned rigidly along the X- 
axis. Thus re-pointing any sensor is equivalent to reorienting the entire spacecraft. 

u • The MSX is severel y resou rce limited (Ref. 6). Power is generated by two solar panels. If 
all the instruments are on and the MSX is tracking a target, the power demand is greater than what 
can be generated by the solar panels even at full illumination. The excess demand is serviced from 
rechargeable Nickel-Hydride batteries. Further, the MSX is in a near-sun-synchronous orbit, and 
as a result, there are extended shadow periods (up to 20 minutes long in an orbital period of 103 
minutes). 

The data storage capability of the MSX is limited. Only one tape recorder can be used at a 
time, and the total data that can be stored is ~36 minutes of data at 25 Mb/s; and 180 minutes of 
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data at 5 Mb/s. These data can be relayed down to only the APL ground station. It takes 2-3 
over the APL ground station to read out all the data on a tape recorder of data. 


passes 


, • a JS o aS severe geometrical constraints (Ref. 6). The most significant of these is 
levied by SPIRIT 3 sensor which is cryogenically cooled by solid hydrogen. Thermal input into 
the sensor from the earth and the sun must be minimized to conserve the depletion of the cryogen 
and prolong the life of the sensor. This necessitates pointing constraints on the +X-axis and the 
Y-axis ot the spacecraft. The other sensors have pointing restrictions along the +X-axis also. 


2.0 SPOCC MISSION PLANNING SYSTEM 


The Mission Planning System has the following requirements: 

1) Command the MSX spacecraft for all surveillance experiments correctly; 

2) Command the SBV in all its operational modes correctly; 

3) Command SPIRIT 3 and UVISI in a restricted set of operational modes correctly in 
support of Surveillance experiments; 

4) Monitor constraints and resource usage; 

5) Provide a high level language interface to the experimenter; 

6) Ensure that modes of operation that are incompatible with the health, safety or 
operational philosophy of the instruments or the spacecraft are precluded; and 

7) Provide a pipelined operational capability in support of rapid and automated 
generation of commanding for experiments. 


The components of the Mission Planning System are shown in Figure 3. 



3.0. THE SIMULATOR 


QT3 j he “ is T he “ rt of * e mission planning pipeline. It simulates the functioning of 

the SBV and the MSX and produces the data necessary to both command the spacecraft and to 
analyze the experiments. 
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3.1. Architecture 


The Simulator is driven by SLED files, either manually created or automatically generated 
by a component called SSIP(see below). The Parser interprets the SLED code and produces a time 
ordered, parameterized queue of events to be simulated along with a set of associated data tables. 
The Simulator takes each SLED generated event and decomposes it into a series of simulation 
events. Each simulation event corresponds to a state change in the simulation, a change in the 
attitude control system or a new set of spacecraft or sensor commands. These events are in turn 
used to drive a standard discrete time simulation. Several graphical, textual and data base/file 
outputs are produced for analysts to examine and also for further processing by the rest of the 
Mission Planning System. 

The primary sensor for the Simulator is the SBV. Hence, there is a detailed model of all the 
permitted operating modes and timelines of that sensor. The distributed nature of commanding of 
the MSX has necessitated an agreement with APL that al9 surveillance experiments will command 
the SBV regardless of any other sensor used. Thus, the timeline of the commanding for any 
experiment is primarily driven by the SBV. The SPIRIT 3 and UVISI sensors, when invoked, are 
used in a restricted set of modes tailored to fit within the constraints of the SBV timing. 

3.2. SLED and the Parser 


SLED is a high level language used to define an experiment for the mission planning 
pipeline (Ref. 7). The major concepts in the SLED language are: 

It is a high level language which permits a description of the experiment. 

It frees the user from the details of the commanding of the sensors. 

It frees the user from worrying about detailed timing of the sensor commanding or the 
experiment operation. 


1 . 

2 . 

3. 


SLED allows a user to describe an entire 
experiment and simulation in a compact format. 
The logical structure of the language is shown in 
Figure 4. The SLED parser, which is the front end 
of the simulator, takes a SLED input file and 
produces a set of data structures used to drive the 
simulation. More importantly, the parser has 
extensive error checking functions which prevent 
inappropriate sensor and infeasible spacecraft 
events from being generated. 



3.3. Models 

3.3.1. Orbital Mechanics 


FIG. 4 : Logical Structure of SLED 


ORB LIB, a set of routines developed at Lincoln Laboratory, is used to determine the 
position of the MSX, resident space objects, the moon and the sun. The simulator is also able to 
accept ephemeris files for the MSX produced by JHU/APL. 

3.3.2. Attitude Control System 


The attitude control system is modeled using software developed at APL. It is essentially 
the same as the system on the spacecraft with mechanical inputs and outputs modeled in software. 
It takes as input a set of files corresponding to spacecraft commands and uploadable parameters 
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and produces an attitude history. Optionally, the operator can select a very simple model, which 
ignores spacecraft dynamics, for quick look and opportunity analysis. 

3.3.3. Power/Thermal Systems 

There is a detailed model of the power system which was also developed at APL. It 
includes modeling of the solar panels, batteries and power electronics. Again, there is a simpler 
model available for quicklook analyses. F 

, , APLbas als ° deve loped a detailed nodal analysis of the spacecraft's critical temperatures. It 
models the effects of solar radiation and internal power consumption. In particular, it calculates the 
temperature of the battery and solar cells which are used as input to the power model. At present it 
is not implemented and much simpler assumptions are being used (i. e. constant battery tempera- 
ture). Both the power and the thermal models ignore transients. 

qptdt^ RC ’ UndCr contra 2; t0 APL ’ has developed a model for the thermal behavior of the 
SPIRIT 3 sensor cryogen. The model takes as inputs the relative position of the sun and earth the 
operating mode of the SPIRIT 3 and the temperatures of the baffle, shell and sunshade. It tracks 
aperture heat load, baffle temperature and cryogen usage. 

3.3.4 Contact Scheduling 

The MSX is a low altitude satellite that must download data stored onboard during short 
contacts with fixed ground stations (on the order of 10 minutes). While the downloading of tape 
recorded data is scheduled by APL, the downloading data stored in SB V RAM is scheduled bythe 

DU °u g ^ ft p ] cal 8u ™ eillance experiment, or data collection event (DCE), the onboard 
SBV RAM may be filled and downloaded several times, requiring several contacts. 

a/iqy planning process is an iterative one. Well in advance of running a DCE on the 

i Simulator ] s run to determine what opportunities exist for a particular experiment. APL 

wnrr h \° n fi th n flt Wlt 5, the °! her DCEs bein S scheduled for other PI teams and sends 
SPOCC schedule files that reflect when DCEs will run. For each scheduled DCE, the simulator is 

™ data iS C ° lleCted in the SB V RAM durin S the course of ^ experiment 

and thereby how many contacts are required. A request for contacts is then made through APL. 

responds with contact scheduling information. The list of contacts, combined with the DCE 
schedule, is used by the simulator to plan the final DCEs which is run on the spacecraft. The 
Simulator contains logic to pause data collection during contacts, and maneuver the spacecraft as 
necessary for contacts over the APL ground station which require a specific attitude. 

3.4. SSIP 

An operational space surveillance sensor must be able to respond to tasking from the 
controlling agency by automatically scheduling the tasks in a sensible, prioritized order taking into 
account visibility, detectability, sensitivity, dynamics, etc. The Space Surveillance Interf^e ® 
Processor provides an automated capability to generate such a schedule - an ordered list of searches 
for or tracks of RSOs - internally to the Simulator. No on-board capability is being implemented 
Instead a ground-based Interface Processor will demonstrate the operational capability^ 

At present, there are two schedulers, one for geosynchronous searches and one for tasking 
experiments. The structure of the software allows for the addition of more scheduling algorithms. 

sirnulatnr S Thl a ^ e t a ta ^? ng n lle as u input and produces SLED files which are in turn used by the 
coTpac^foTmat bng ^ & ° WS ^ ^ t0 Specify a com P llcated scheduling scenario in a very 
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a T u ere 316 two c ? nce P ts of * nterest in SSIP, pseudo-objects and the figure of merit (FOM) 
Pseudo-objects are used to produce search spaces. For instance, to search along the geosynchro- 
nous belt a set of pseudo-objects would be generated. Each object would have a mean anomaly 
approximately one field of view apart. As SSIP generates a search for each object, the search space 
is covered. The FOM is a computed scalar used to determine which object should be tracked next. 
It is calculated by multiplying a senes of weighting factors. These factors pertain to the geometry 
and dynamics of the orbits of the RSOs, the reflectivity-area product of the RSOs and the 
characteristics of the background against which the RSOs are detected. 

3.5. Outputs 

3.5.1. Instantiated Mission Timeline 

, The instantiated mission timeline or IMT file is a time ordered, time-tagged list of the events 
that occurred dunng the simulation. The IMT file is passed on to the ACG/CVT where it is 
translated into spacecraft commands. It is an ASCII text file which can also be examined bv the 
operator to see the results of a simulation. ^ 

3.5.2. The PLOT and Attitude Files 

A da * a f de containing the details of the simulation is also produced. The data includes 
constraint angles, power and thermal data, target information and ground station information. This 

AnafysiTsysteTcRef *) PROGRAPH and Good -t™es processors of the Opportunity/Feasibility 

., . , The athtu^ data file contains a detailed listing of the position and attitude of the spacecraft, 

Asrn he r SB Lv e ' £ C ° rmn ! he /; gain etc) and tar s et data - It is also a operator readable 
AiCll text file. In addition the attitude file can be used to produce simulated SBV imagery. 

3.5.3. Cost Reports 

anaW a ] s ° P roduces a c °mpact listing of resource usage data of most interest to an 

analyst. These data includes power/thermal values, avoidance angles and timing information. 

These costs are validated by comparing with the more detailed models used by APL. 

4.0 COMMAND GENERATION 

T , Simulator, as described above, generates an Integrate Mission Timeline (IMT) file. 

1 he IMT file contains a sequence of spacecraft and sensor commanding events. The Automatic 
Command Generator (ACG) and Command Vettor & Translator (CVT) complete the mission 
P roce ^ s by converting the high level event description in the IMT file to the SBV and 
MSX commands that will accomplish the specified events. 

4.1 Automatic Command Generator (ACG) 

Arr l C ^ P ^ dS u ea ^ event in the int0 a se( l uence of mnemonic commands. The 
ACG parses the IMT file building an event queue from the sequence of spacecraft and sensor 

commanding events Each event is processed sequentially, and is converted into one or more 
mnemonic commands. Each mnemonic represents either a 32 bit SBV serial command or an APL 
command packet for an MSX subsystem or another sensor such as the SPIRIT III The mnemonic 
commands are written out to an MNE file, short for mnemonics. The mnemonic commands are m 
intermediate level of commanding designed to be easier to read than 32 bit hex commands and is 
used primarily for debugging purposes. The mnemonic commands can also be used for writing 
SBV contingency scripts that do not require simulation of the spacecraft and other sensors. 
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4.2 Command Vettor & Translator (CVT) 

The CVT translates the MNE file mnemonics into the commands that will be transmitted to 
APL for commanding the MSX and its sensors. The CVT vets and translates each SB V mnemonic 
into its corresponding 32 bit serial command value. The CVT translates each APL command 
packet mnemonic into the sequence of APL command domain identifiers corresponding to the 
command packet for that spacecraft subsystem or sensor. The 32 bit commands and domain 
identifiers are output to the Event Definition Format (EDF) file which is then transmitted to APL. 
The Mission Operations Center at APL processes the EDF file, converts the domain identifiers into 
32 bit serial commands and builds a command upload for the MSX spacecraft. 

The CVT also generates a second output file named the REQ file. The REQ file is used for 
testing the experiment’s SBV commands on the SBV brassboard. The REQ file contains the same 
32 bit SBV commands as the EDF file, but the MSX command domain identifiers are replaced by 
commands to the brassboard’s ground support equipment (GSE). As the SBV commands execute 
on the brassboard, the GSE simulates the MSX spacecraft subsystems that interface with the SBV. 

5.0. DATABASES 

During a Simulator run, several types of data are retrieved from various databases. A 
Master Object File (MOF) database provides information on resident space objects. A second 
database provides schedule information regarding which data collection events are to run when. 
Information regarding the contact schedule for data downloads is also present in a third database. 
Both of these databases are used for planning DCEs to take advantage of the ground station 
contacts available for downloading collected data. 

6.0 PIPELINE AND AUTOMATION 

The Simulator, ACG, and CVT constitute the core of the SPOCC Mission Planning System 
pipeline that is run end to end for each 
data collection event to be run on the 
MSX. The SPOCC Mission Planning 
System incorporates several types of 
automation to minimize human operator 
workload during mission planning 
(Figure 5). 


The event schedule and contact 
schedule information arrives from APL 
as various files which are automatically 
processed upon receipt, archived, and 
the appropriate data entered into the 
databases. Several other files needed 

for mission planning, such as orbital geometry files, also arrive from APL and are automatically 
processed and archived. J 

The pieces of the pipeline can be run either individually, or the whole pipeline can be run 
with one call to a script. A script is also available to assist the mission planners in properly naming 
SLED files, as well as one which automatically archives the pipeline output files, transmits the 
EDF and cost report files to APL, and updates a database as to what files where sent. 



Fig. 5: Automation of SPOCC Mission Planning Pipeline 
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7.0 TESTING 




Several levels of testing are used to ensure to correct operation of the pipeline during its 
development. As new features and capabilities are added, developmental unit testing on the 
individual pieces of the pipeline are carried out. With each major release of the whole pipeline a 
series of standard regression tests are run to verify the new release. 

PD , r , As each new type of data collection event is developed, its REQ file is first run through the 
SBV brassboard to verify that the SBV portion of the commanding is correct. The EDF is then 
sent to APL for feasibility testing with their MSX spacecraft simulation. Several types of 
surveillance data collection events have also been run on the MSX spacecraft hardware itself during 
ground testing as part of the MSX integration and testing effort. 

8.0 SUMMARY 

A capable mission planning system has been designed and built for space surveillance 
experiments with the MSX satellite. While primarily designed for experiments with the SBV 
sensor built by MIT/LL, the system has been expanded to accommodate other sensors on board 
and also the commanding of the MSX itself. The entire system is designed to be driven by an 
experiment description in a high level language and a set of data bases. The system can be operated 
in a pipelined fashion. Comprehensive unit, subsystem and system testing is accomplished with 
speciany designed regression tests. This is followed by validation through a brassboard of the 
bBV and the spacecraft simulator. The system will be operational at launch of the spacecraft 
expected at the end of 1994. F 
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